Review (camera smoothing)

Nice improvement for fixed-camera world-space follow. Smoothing the packet-driven attached/tracked positions and adding snap-on-teleport should eliminate the small jitter you can get when those positions arrive quantized / irregularly.

What looks good

• attachedToPosition + trackedPosition now have targets + client-side lerp with a deadzone; this should noticeably reduce camera micro-jitter without needing higher net update rates.
• Snap thresholds for big deltas avoid “smoothing through walls” after teleports.
• updateProjectionMatrix() only when filmOffset/fov/zoom actually change.
• Reuse of temp vectors (shoulderRotationAxis, spectatorForward/right) avoids per-frame/per-packet allocations.

Things to double-check (possible behavior changes)

• _updateGameCameraOrientation() now normalizes yaw to [-π, π] and suppresses tiny changes via CAMERA_ORIENTATION_EPSILON. If any server/game logic assumes yaw is unwrapped/monotonic, you could see wrap-around jumps near ±π unless the receiver also normalizes/handles angle wrapping.
• The new smoothing introduces a small lag (~60–80ms time constants) for attachedToPosition / trackedPosition. That’s probably desired for “fixed camera follow”, but if any games use these fields for cutscenes where the camera must match an exact authored path per tick, you may want an opt-out (or make lerp/snap tunables).
• Hard-coded thresholds (*_SNAP_DISTANCE_*, deadzone) assume “human scale” meters; if some games use very small/large world scales, these may need tuning.

Perf / mobile vs desktop

• Should be a net win: fewer projection updates + fewer allocations. The extra exp() per frame is negligible.
• Smoothing is frameDeltaS-based so it should behave consistently across variable FPS (mobile included).

(Also worth noting upstream PR #10 is stacked on #9; this fork PR is stacked on fork PR #7 to keep the diff focused.)